本文关注的主要是内核如何处理DTB文件中记录的设备信息，会分析内核解析DTB文件的主体流程，不会关注所有细节，同时，也不会关注对特定设备信息的处理，比如对有关中断的设备信息的处理，相关内容在做相应模块的笔记时再细究（学习linux的中断管理时会分析内核对DTB中有关中断的部分的处理）。

前文已经说过，DTB文件由u-boot传递给内核，u-boot在跳转到内核时，会把一些关键的信息通过参数（实际使用通用寄存器r0、r1、r2）传递给内核：

可见，当u-boot向内核传递DTB文件时，内核真正要关注的只有r2寄存器中存放的DTB文件的内存起始地址。内核会在启动的汇编阶段把这个地址保存到全局变量__atags_pointer，大体的过程如下：

kernel启动的汇编阶段结束后，会跳转执行start_kernel，此时__atags_pointer指向内存中的DTB文件。kernel对DTB的解析在start_kernel==>setup_arch函数中进行。kernel将DTB中的信息分为三类：

下文将分别介绍内核对这三种信息的处理。

一个kernel镜像通常会支持很多板子，针对每种板子，kernel都会为其定义一个struct machine_desc的结构，其中就记录各个板子的硬件信息，比如板子的ID号、名字、支持的中断数量、初始化函数等。这样，在kernel启动时，可以根据u-boot传递的参数/DTB文件选则合适的machine_desc，从而正确的初始化当前硬件。

kernel会将一系列machine_desc集中存放在.init.arch.info节中，形成如同数组一样的内存分布：

并以符号__arch_info_begin和__arch_info_end记录该节的起始和结尾，如此一来，就可以向访问数组元素那样访问每个machine_desc。

在选则machine_desc时，kernel首先会获取DTB的根节点的compatible属性，将其中的一个或多个字符串与machine_desc的dt_compat成员记录的一个或多个字符串进行比较，当匹配时，返回相应的machine_desc。值得一提的是，compatible属性值中，位置靠前的字符串会优先比较，换句话说，位置越靠前说明该字符串指示的machine_desc越适合当前单板。

有了2.1节的铺垫，接下来就可以进行源码分析了，从setup_arch开始：

由上文可知，setup_arch函数调用setup_machine_fdt解析设备树中的相关信息，并返回合适的machine_desc：

of_flat_dt_match_machine函数是匹配合适的machine_desc的关键：

至此，如何根据DTB的根节点的compatible属性匹配machine_desc就介绍完了。

kernel使用setup_arch ==> setup_machine_fdt ==> early_init_dt_scan_nodes来处理DTB中的运行时配置信息：

要进一步了解其中的细节，我们需要先弄清楚of_scan_flat_dt函数做了什么：

不难看出，该函数只是一个遍历设备树节点的工具函数：遍历设备树节点，调用回调函数，如果回调函数判断该节点就是想要解析的节点，则进行相应的解析操作，并返回非0值，以指示该函数停止遍历动作。

根据函数名字，以及3.1节的分析，猜也应该猜到传入的回调函数early_init_dt_scan_chosen用于解析/chosen节点：

在解析/memory节点之前，应该先得到根节点的{size,address}-cells属性值，因为/memory节点使用reg属性来存放内存的起始地址和长度，而解析reg属性少不了{size,address}-cells。

是时候解析/memory节点了：

至此，内核对运行时配置信息的处理就介绍完了。

内核会保留DTB所占据的内存区域，因此DTB文件中的数据在kernel启动后也是可用的，相关源码的调用路径如下：

DTB文件的structure block区域记录了很多设备节点，每个节点又有很多属性，对此，kernel使用struct device_node来描述节点，使用struct property来描述属性。下面就介绍一下这两个结构的主要成员（不是全部成员）：

struct device_node：

struct property：

kernel调用unflatten_device_tree函数，将DTB文件中的设备节点转换为一个个的struct device_node，这些结构体有着树状的层次，在分析相关源码之前，我们不妨先看一个设备树完成转换之后的结果，建立起总体上的认知。

首先给出一个设备树文件的示例，这个设备树文件并不完整，只是用作示例：

该设备树文件被DTC编译为DTB之后，被u-boot传递给kernel，然后内核读取其节点信息，建立如下的由device_node构成的树状结构： 值得一提的是，为了突出device_node的name成员和full_name成员的差别，在上图中，我将没有name属性的节点的name成员置为，这源于：

但实际上，populate_properties函数会为没有name属性的节点创建name属性：

有了上文的铺垫，我们就可以开始从源码的层面分析kernel如何根据DTB构建device_node树：

再看__unflatten_device_tree：

of_platform_default_populate只是of_platform_populate的简单包装，因此我们直接看后者：

再看of_platform_bus_create：

函数of_platform_device_create_pdata会调用of_device_alloc以及of_device_add创建并注册platform_device，具体的就不再跟踪了。

上文已经说过，对于compatible属性为simple-bus等特殊值的节点，kernel也会为其含有compatible属性的子节点创建platform_device。那么对于其他设备节点呢，怎么处理它们的子节点？所谓知子莫若父，它们的子节点应该交由父节点（也就是创建了platform_device的节点）来处理。仍以4.5.1节中i2c的例子来说明。

kernel为该节点创建platform_device后，将其注册到platform_bus_type，根据kernel的总线-设备-驱动模型，如果该节点的compatible属性samsung,s3c2410-i2c，匹配总线上的某个platform_driver，那么该驱动的probe函数会被调用，在该函数中，会为SoC的i2c控制器创建i2c_adapter，也会为连接在该控制器上的i2c接口的外设eeprom@50创建i2c_client。具体的函数调用过程放在4.6节，这里就不再多说了。

kernel源码树下的include/linux目录下存在着一些以of开头的头文件，这些头文件内是一些与设备树相关的函数的声明。下面将对这些头文件做一个分类。

所有设备树的信息存放于/sys/firmware目录下：

所有的platform_device会在/sys/devices/platform下对应一个目录，这些platform_device有来自设备树的，也有来自.c文件中手工注册的。由kernel根据设备树创建的platform_device对应的目录下存在一个名为of_node的软链接，链接向该platform_device对应的device_node对应的目录。

/proc/device-tree作为链接文件指向/sys/firmware/devicetree/base。

[1] linux-kernel-5.4.26源码及文档 [2] 韦东山老师的设备树视频教程